Amazon Redshift Serverless 本番環境に向けた「設定をカスタマイズ」による環境構築手順

石川覚

2022.08.08

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

データアナリティクス事業本部コンサルティングチームの石川です。「デフォルト設定を使用」で構築するのであれば、ワンクリック3分で構築可能です。

しかし、本番環境のように任意のVPCに構築するには「設定をカスタマイズ」による環境構築が必要です。

1つ目のRedshift Serverless環境の構築は、「デフォルト設定を使用」を用いた環境構築もしくは「設定をカスタマイズ」による環境構築のいずれかです。2つ目以降は、下記のサーバーレスダッシュボードの[ワークグループを作成]から環境構築します。この手順は、「設定をカスタマイズ」とほぼ同じで、RPUの設定が追加されたものとそれほど変わりません。

本日は、Redshift Serverlessを構築するための設定項目の整理して、「設定をカスタマイズ」による環境構築する手順について解説します。

環境構築するための設定項目

最初にRedshift Serverlessを構築する前に、以下の要件について整理します。

名前空間（Namespace）

Namespace（名前空間）は、関連付けられたデータベースリソース、スナップショット、暗号化キー、およびユーザー等を作成します。

名前空間の名前（Namespace Name）

名前空間の名前を指定します。ここで指定した文字列がエンドポイントの先頭の文字になります。

データベース名

データベース名は、devで固定です。

管理ユーザの認証情報

IAMクレデンシャルに基づいてadminユーザーのパスワードが生成されます。任意の管理ユーザ名やパスワードを設定（自動もしくは任意）が可能です。

Security and encryption

暗号化キーは、デフォルトではAWS が所有するキー（AWS Owned Key）で暗号化されます。任意のAWS カスタマーマネージドキー（CMK：Customer Managed Key）を選択することもできます。

監査ログは、以下のログ出力を選択できます。なお、Redshift Serverlessは、S3への出力はなく、CloudWatch Logsへの出力のみとなります。

ユーザーログ
接続ログ
ユーザーアクティビティログ

ワークグループ（Workgroup）

ワークグループは、ワークロードの処理に使用できるネットワークやコンピューティングリソースを定義します。（ここで、設定できるのは、ネットワークのみです。）

ワークグループの名前（Workgroup Name）

ワークグループの名前を指定します。個人的な見解として、名前空間とワークグループは、1対1の関係なので同じ名前を付けておいた方が管理しやすいため、あえて異なる名前をつける必要はないと考えられます。

VPC

構築したいVPC IDを指定します。

VPC セキュリティグループ

Redshift Serverless用のセキュリティグループIDを指定します。

サブネット

Redshift Serverlessのエンドポイントを作成するサブネットを指定します。Provisioned Clusterのサブネットグループに相当するものです。Redshift Serverlessは、少なくとも3つのサブネットが必要で、それらが3つのアベイラビリティゾーンにまたがっている必要があります。

拡張 VPC ルーティング

デフォルトでは、OFF（無効）です。

導入手順

マネジメントコンソールでRedshiftの画面を開くと、左のナビゲーションメニューが閉じた状態で表示されます。左上の ≡ のアイコンをクリックすると下記のように、左のナビゲーションメニューが展開され、上に[Redshift サーバレス新規]をクリックします。

サーバレスダッシュボードの「設定をカスタマイズ」を選択します。

名前空間（Namespace）の設定

名前空間の名前（Namespace Name）: severlessを指定
データベース名: devで固定
管理ユーザの認証情報:「管理者ユーザー認証情報をカスタマイズ」にチェックを入れて、任意のパスワードを設定

関連付けられた IAM ロール: [IAMロールの管理 ▼]から[IAMロールを作成]を選択

「デフォルトのIAMロールを作成する」ダイアログで、「任意のS3バケット」を選択した状態で、[IAMロールをデフォルトとして作成する]を押します

すると、IAMロールが自動的に作成されて、アタッチされます

暗号化設定をカスタマイズする (高度): チェックを入れて、[AWS カスタマーマネージドキーを選択]で、事前に作成しておいたカスタマーマネージドキーredshift-serverless（CMK：Customer Managed Key）を選択（選択すると、自動的にARNに置き換わる）

監査ログは、以下の3つログ出力を選択、出力先はCloudWatch Logsへの出力のみとなります。

ユーザーログ
接続ログ
ユーザーアクティビティログ

ワークグループ（Workgroup）の設定

ワークグループの名前（Workgroup Name）: severless-wgを指定
VPC: 構築したいVPC IDを指定: vpc-xxxxxxxxを指定
VPC セキュリティグループ: sg-xxxxxxxxを指定する
サブネット: subnet-aaaaaaaa,subnet-bbbbbbbb,subnet-cccccccc、少なくとも3つのサブネットかつ3つのアベイラビリティゾーンにまたがっている
拡張された VPC のルーティング: [拡張された VPC ルーティングをオンにする]をチェックしない

最後に[設定を保存]を押すと直ちに作成されます。3分程度で、Redshift Serverlessが利用できるようになります。

導入後のカスタマイズしたほうが良い設定

Base RPU capacity

ベースラインパフォーマンスは、デフォルトが、128（32-512）です。RPU（Redshift Processing Unit）は、コンピューティングを表す単位で、1RPUあたり16GiBメモリ、時間に対して秒単位で課金されます。

ワークグループの設定を開き、[制限]タブを選択、[編集]ボタンを押す。

デフォルトの128を、任意の値に設定して、[変更を保存]ボタンを押します。

補足：自動生成されたデフォルトのIAMロールの内容

「デフォルトのIAMロールを作成する」ダイアログで作成したAmazonRedshift-CommandsAccessRole-20220808T025808について、補足します。このIAMロールは、AmazonRedshift-CommandsAccessPolicy-20220808T025808というカスタマ管理ポリシーとAmazonRedshiftAllCommandsFullAccessというAWS管理ポリシーが含まれます。

カスタマ管理ポリシーの内容

カスタマ管理ポリシーのAmazonRedshift-CommandsAccessRole-20220808T025808の内容は、以下のとおりです。AmazonRedshiftAllCommandsFullAccessに含まれないRedshiftに必要となる全てのS3リソースに対するアクションが追加されています。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "s3:GetObject",
                "s3:GetBucketAcl",
                "s3:GetBucketCors",
                "s3:GetEncryptionConfiguration",
                "s3:GetBucketLocation",
                "s3:ListBucket",
                "s3:ListAllMyBuckets",
                "s3:ListMultipartUploadParts",
                "s3:ListBucketMultipartUploads",
                "s3:PutObject",
                "s3:PutBucketAcl",
                "s3:PutBucketCors",
                "s3:DeleteObject",
                "s3:AbortMultipartUpload",
                "s3:CreateBucket"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:s3:::*"
        }
    ]
}

最後に

Redshift Serverlessは、これまでのRedshift （Provisioned Cluster）が持つほぼ全て機能と接続性を備えたその名の通り、インスタンスを持たないサーバレスなRedshiftです。クライアントアプリケーションからは一見全く同じサービスと思うほどの完成度ですが、インフラエンジニア視点では注意が必要です。

Redshiftクラスタ（Provisioned Cluster）とRedshift Serverlessの新規構築での大きな違いは、ネットワークです。Redshift Serverlessは、少なくとも3つのサブネットが必要で、それらが3つのアベイラビリティゾーンにまたがっている必要があることです。また、RPUの数に応じてENIをより多く確保する必要があり、VPCやSubnetのCIDRは従来よりも大きく確保することを忘れずにインフラを設計してください。

この点をクリアできれば、メンテナンスウインドのない、リニアにスケールするサーバーレスなDWHをご利用いただけます。